* [PATCH] btrfs: clear file extent mapping for punch past i_size
From: Josef Bacik @ 2020-02-20 14:29 UTC (permalink / raw)
To: linux-btrfs, kernel-team
In my stress testing we were still seeing some hole's with my patches to
fix missing hole extents. Turns out we do not fill in holes during hole
punch if the punch is past i_size. I incorrectly assumed this was fine,
because anybody extending would use btrfs_cont_expand, however there is
a corner that still can give us trouble. Start with an empty file and
fallocate KEEP_SIZE 1m-2m
We now have a 0 length file, and a hole file extent from 0-1m, and a
prealloc extent from 1m-2m. Now
punch 1m-1.5m
Because this is past i_size we have
[HOLE EXTENT][ NOTHING ][PREALLOC]
[0 1m][1m 1.5m][1.5m 2m]
with an i_size of 0. Now if we pwrite 0-1.5m we'll increas our i_size
to 1.5m, but our disk_i_size is still 0 until the ordered extent
completes.
However if we now immediately truncate 2m on the file we'll just call
btrfs_cont_expand(inode, 1.5m, 2m), since our old i_size is 1.5m. If we
commit the transaction here and crash we'll expose the gap.
To fix this we need to clear the file extent mapping for the range that
we punched but didn't insert a corresponding file extent for. This will
mean the truncate will only get an disk_i_size set to 1m if we crash
before the finish ordered io happens.
I've written an xfstest to reproduce the problem and validate this fix.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
- Dave, this needs to be folded into "btrfs: use the file extent tree
infrastructure" and the changelog needs to be adjusted since I incorrectly
point out that we don't need to clear for hole punch. We definitely need to
clear for the case that we're punching past i_size as we aren't inserting hole
file extents.
fs/btrfs/file.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 5cdcdbdd908b..6f6f1805e6fd 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2597,6 +2597,24 @@ int btrfs_punch_hole_range(struct inode *inode, struct btrfs_path *path,
btrfs_abort_transaction(trans, ret);
break;
}
+ } else if (!clone_info && cur_offset < drop_end) {
+ /*
+ * We are past the i_size here, but since we didn't
+ * insert holes we need to clear the mapped area so we
+ * know to not set disk_i_size in this area until a new
+ * file extent is inserted here.
+ */
+ ret = btrfs_inode_clear_file_extent_range(BTRFS_I(inode),
+ cur_offset, drop_end - cur_offset);
+ if (ret) {
+ /*
+ * We couldn't clear our area, so we could
+ * presumably adjust up and corrupt the fs, so
+ * we need to abort.
+ */
+ btrfs_abort_transaction(trans, ret);
+ break;
+ }
}
if (clone_info && drop_end > clone_info->file_offset) {
@@ -2687,6 +2705,15 @@ int btrfs_punch_hole_range(struct inode *inode, struct btrfs_path *path,
btrfs_abort_transaction(trans, ret);
goto out_trans;
}
+ } else if (!clone_info && cur_offset < drop_end) {
+ /* See the comment in the loop above for the reasoning here. */
+ ret = btrfs_inode_clear_file_extent_range(BTRFS_I(inode),
+ cur_offset, drop_end - cur_offset);
+ if (ret) {
+ btrfs_abort_transaction(trans, ret);
+ goto out_trans;
+ }
+
}
if (clone_info) {
ret = btrfs_insert_clone_extent(trans, inode, path, clone_info,
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v3 02/10] ASoC: tegra: add support for CIF programming
From: Jon Hunter @ 2020-02-20 14:30 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-3-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> Audio Client Interface (CIF) is a proprietary interface employed to route
> audio samples through Audio Hub (AHUB) components by inter connecting the
> various modules.
>
> This patch exports an inline function tegra_set_cif() which can be used,
> for now, to program CIF on Tegra210 and later Tegra generations. Later it
> can be extended to include helpers for legacy chips as well.
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> sound/soc/tegra/tegra_cif.h | 63 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 sound/soc/tegra/tegra_cif.h
>
> diff --git a/sound/soc/tegra/tegra_cif.h b/sound/soc/tegra/tegra_cif.h
> new file mode 100644
> index 0000000..ecc0850
> --- /dev/null
> +++ b/sound/soc/tegra/tegra_cif.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * tegra_cif.h - TEGRA Audio CIF Programming
> + *
> + * Copyright (c) 2020 NVIDIA CORPORATION. All rights reserved.
> + *
> + */
> +
> +#ifndef __TEGRA_CIF_H__
> +#define __TEGRA_CIF_H__
> +
> +#define TEGRA_ACIF_CTRL_FIFO_TH_SHIFT 24
> +#define TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT 20
> +#define TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT 16
> +#define TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT 12
> +#define TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT 8
> +#define TEGRA_ACIF_CTRL_EXPAND_SHIFT 6
> +#define TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT 4
> +#define TEGRA_ACIF_CTRL_REPLICATE_SHIFT 3
> +#define TEGRA_ACIF_CTRL_TRUNCATE_SHIFT 1
> +#define TEGRA_ACIF_CTRL_MONO_CONV_SHIFT 0
> +
> +/* AUDIO/CLIENT_BITS values */
> +#define TEGRA_ACIF_BITS_8 1
> +#define TEGRA_ACIF_BITS_16 3
> +#define TEGRA_ACIF_BITS_24 5
> +#define TEGRA_ACIF_BITS_32 7
> +
> +#define TEGRA_ACIF_UPDATE_MASK 0x3ffffffb
> +
> +struct tegra_cif_conf {
> + unsigned int threshold;
> + unsigned int audio_ch;
> + unsigned int client_ch;
> + unsigned int audio_bits;
> + unsigned int client_bits;
> + unsigned int expand;
> + unsigned int stereo_conv;
> + unsigned int replicate;
> + unsigned int truncate;
> + unsigned int mono_conv;
> +};
> +
> +static inline void tegra_set_cif(struct regmap *regmap, unsigned int reg,
> + struct tegra_cif_conf *conf)
> +{
> + unsigned int value;
> +
> + value = (conf->threshold << TEGRA_ACIF_CTRL_FIFO_TH_SHIFT) |
> + ((conf->audio_ch - 1) << TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT) |
> + ((conf->client_ch - 1) << TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT) |
> + (conf->audio_bits << TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT) |
> + (conf->client_bits << TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT) |
> + (conf->expand << TEGRA_ACIF_CTRL_EXPAND_SHIFT) |
> + (conf->stereo_conv << TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT) |
> + (conf->replicate << TEGRA_ACIF_CTRL_REPLICATE_SHIFT) |
> + (conf->truncate << TEGRA_ACIF_CTRL_TRUNCATE_SHIFT) |
> + (conf->mono_conv << TEGRA_ACIF_CTRL_MONO_CONV_SHIFT);
> +
> + regmap_update_bits(regmap, reg, TEGRA_ACIF_UPDATE_MASK, value);
> +}
> +
> +#endif
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers!
Jon
--
nvpublic
^ permalink raw reply
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Force PSR probe only after full initialization (rev5)
From: Patchwork @ 2020-02-20 14:30 UTC (permalink / raw)
To: Ross Zwisler; +Cc: intel-gfx
In-Reply-To: <20200218203916.58636-1-jose.souza@intel.com>
== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev5)
URL : https://patchwork.freedesktop.org/series/73436/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16607_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
New tests
---------
New tests have been introduced between CI_DRM_7963_full and Patchwork_16607_full:
### New IGT tests (58) ###
* igt@i915_pm_backlight@bad-brightness:
- Statuses : 3 pass(s) 4 skip(s)
- Exec time: [0.0, 0.03] s
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 0.24] s
* igt@i915_pm_backlight@fade:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 2.59] s
* igt@i915_pm_backlight@fade_with_dpms:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.92] s
* igt@i915_pm_backlight@fade_with_suspend:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.54] s
* igt@i915_pm_lpsp@edp-native:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.04] s
* igt@i915_pm_lpsp@edp-panel-fitter:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.05] s
* igt@i915_pm_lpsp@non-edp:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.12] s
* igt@i915_pm_lpsp@screens-disabled:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.05] s
* igt@i915_pm_rc6_residency@media-rc6-accuracy:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rc6_residency@rc6-accuracy:
- Statuses : 8 pass(s)
- Exec time: [3.0, 3.00] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 7 pass(s)
- Exec time: [0.25, 5.02] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [1.30, 11.45] s
* igt@i915_pm_rpm@cursor:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 41.78] s
* igt@i915_pm_rpm@cursor-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 41.22] s
* igt@i915_pm_rpm@debugfs-forcewake-user:
- Statuses : 7 pass(s)
- Exec time: [10.44, 14.38] s
* igt@i915_pm_rpm@debugfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 80.93] s
* igt@i915_pm_rpm@dpms-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 0.82] s
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 13.27] s
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 4.14] s
* igt@i915_pm_rpm@dpms-non-lpsp:
- Statuses : 4 pass(s) 3 skip(s)
- Exec time: [0.0, 0.16] s
* igt@i915_pm_rpm@drm-resources-equal:
- Statuses : 7 pass(s)
- Exec time: [0.79, 9.69] s
* igt@i915_pm_rpm@fences:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 16.91] s
* igt@i915_pm_rpm@fences-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 12.80] s
* igt@i915_pm_rpm@gem-evict-pwrite:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 3.97] s
* igt@i915_pm_rpm@gem-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 15.56] s
* igt@i915_pm_rpm@gem-execbuf-stress:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 42.66] s
* igt@i915_pm_rpm@gem-execbuf-stress-pc8:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.00] s
* igt@i915_pm_rpm@gem-idle:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.26] s
* igt@i915_pm_rpm@gem-pread:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 6.15] s
* igt@i915_pm_rpm@i2c:
- Statuses : 7 pass(s)
- Exec time: [0.94, 11.24] s
* igt@i915_pm_rpm@legacy-planes:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 169.38] s
* igt@i915_pm_rpm@legacy-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 146.54] s
* igt@i915_pm_rpm@modeset-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.76] s
* igt@i915_pm_rpm@modeset-lpsp-stress:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 53.13] s
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 16.77] s
* igt@i915_pm_rpm@modeset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 4.00] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 9.55] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 6.65] s
* igt@i915_pm_rpm@modeset-pc8-residency-stress:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 72.05] s
* igt@i915_pm_rpm@pc8-residency:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@pm-caching:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 19.56] s
* igt@i915_pm_rpm@pm-tiling:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 16.86] s
* igt@i915_pm_rpm@reg-read-ioctl:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 8.09] s
* igt@i915_pm_rpm@sysfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 3.94] s
* igt@i915_pm_rpm@system-suspend:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.06] s
* igt@i915_pm_rpm@system-suspend-devices:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 13.53] s
* igt@i915_pm_rpm@system-suspend-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 86.05] s
* igt@i915_pm_rpm@system-suspend-modeset:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 13.73] s
* igt@i915_pm_rpm@universal-planes:
- Statuses : 7 pass(s)
- Exec time: [2.86, 226.26] s
* igt@i915_pm_rpm@universal-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 195.60] s
* igt@i915_pm_rps@basic-api:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.03] s
* igt@i915_pm_rps@min-max-config-idle:
- Statuses : 8 pass(s)
- Exec time: [0.11, 0.63] s
* igt@i915_pm_rps@min-max-config-loaded:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [0.32, 3.02] s
* igt@i915_pm_rps@reset:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [3.52, 3.66] s
* igt@i915_pm_rps@waitboost:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [2.52, 2.63] s
* igt@i915_pm_sseu@full-enable:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 0.01] s
Known issues
------------
Here are the changes found in Patchwork_16607_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +8 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_busy@busy-vcs1.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb7/igt@gem_busy@busy-vcs1.html
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_ctx_shared@exec-single-timeline-bsd.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html
* igt@gem_exec_schedule@pi-userfault-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_exec_schedule@pi-userfault-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@gem_exec_schedule@pi-userfault-bsd.html
* igt@gem_exec_schedule@preempt-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +4 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@gem_exec_schedule@preempt-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb1/igt@gem_exec_schedule@preempt-bsd.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#644])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@gem_ppgtt@flink-and-close-vma-leak.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@gen7_exec_parse@basic-offset:
- shard-hsw: [PASS][11] -> [FAIL][12] ([i915#694])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw8/igt@gen7_exec_parse@basic-offset.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-hsw5/igt@gen7_exec_parse@basic-offset.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#454])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
* igt@i915_suspend@sysfs-reader:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl7/igt@i915_suspend@sysfs-reader.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-apl4/igt@i915_suspend@sysfs-reader.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +2 similar issues
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#72])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk2/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-glk3/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
* igt@kms_flip@flip-vs-absolute-wf_vblank:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#488])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-tglb7/igt@kms_flip@flip-vs-absolute-wf_vblank.html
* igt@kms_flip@plain-flip-ts-check:
- shard-skl: [PASS][23] -> [FAIL][24] ([i915#34])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl8/igt@kms_flip@plain-flip-ts-check.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl5/igt@kms_flip@plain-flip-ts-check.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- shard-tglb: [PASS][25] -> [SKIP][26] ([i915#668]) +3 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-skl: [PASS][27] -> [FAIL][28] ([i915#49])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl9/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][29] -> [FAIL][30] ([fdo#108145])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][31] -> [SKIP][32] ([fdo#109441]) +2 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb3/igt@kms_psr@psr2_cursor_mmap_cpu.html
* igt@perf@oa-exponents:
- shard-glk: [PASS][33] -> [FAIL][34] ([i915#84])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk6/igt@perf@oa-exponents.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-glk5/igt@perf@oa-exponents.html
* igt@prime_busy@hang-bsd2:
- shard-iclb: [PASS][35] -> [SKIP][36] ([fdo#109276]) +16 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@prime_busy@hang-bsd2.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb8/igt@prime_busy@hang-bsd2.html
#### Possible fixes ####
* {igt@gem_ctx_persistence@close-replace-race}:
- shard-iclb: [FAIL][37] ([i915#1241]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_ctx_persistence@close-replace-race.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb1/igt@gem_ctx_persistence@close-replace-race.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [SKIP][39] ([fdo#110854]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_exec_balancer@smoke.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb4/igt@gem_exec_balancer@smoke.html
* {igt@gem_exec_schedule@implicit-read-write-bsd}:
- shard-iclb: [SKIP][41] ([i915#677]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@gem_exec_schedule@implicit-read-write-bsd.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb3/igt@gem_exec_schedule@implicit-read-write-bsd.html
* {igt@gem_exec_schedule@implicit-write-read-bsd1}:
- shard-iclb: [SKIP][43] ([fdo#109276] / [i915#677]) -> [PASS][44]
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@gem_exec_schedule@implicit-write-read-bsd1.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb1/igt@gem_exec_schedule@implicit-write-read-bsd1.html
* igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [SKIP][45] ([fdo#112146]) -> [PASS][46] +5 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@gem_exec_schedule@in-order-bsd.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb8/igt@gem_exec_schedule@in-order-bsd.html
* igt@gem_exec_schedule@promotion-bsd1:
- shard-iclb: [SKIP][47] ([fdo#109276]) -> [PASS][48] +17 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@gem_exec_schedule@promotion-bsd1.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb1/igt@gem_exec_schedule@promotion-bsd1.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-apl: [FAIL][49] ([i915#644]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-apl6/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@kms_cursor_crc@pipe-a-cursor-size-change:
- shard-snb: [SKIP][51] ([fdo#109271]) -> [PASS][52] +1 similar issue
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-snb4/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-snb1/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [FAIL][53] ([i915#96]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw8/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-hsw2/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [DMESG-WARN][55] ([i915#180]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl3/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw: [INCOMPLETE][57] ([i915#61]) -> [PASS][58]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@kms_flip@flip-vs-suspend-interruptible.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-hsw1/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_frontbuffer_tracking@psr-1p-rte:
- shard-tglb: [SKIP][59] ([i915#668]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-tglb7/igt@kms_frontbuffer_tracking@psr-1p-rte.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [DMESG-WARN][61] ([i915#180]) -> [PASS][62] +1 similar issue
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-apl7/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [FAIL][63] ([fdo#108145]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_psr2_su@page_flip:
- shard-iclb: [SKIP][65] ([fdo#109642] / [fdo#111068]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@kms_psr2_su@page_flip.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@kms_psr2_su@page_flip.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [SKIP][67] ([fdo#109441]) -> [PASS][68] +2 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@kms_psr@psr2_primary_mmap_cpu.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl: [INCOMPLETE][69] ([i915#69]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-kbl: [INCOMPLETE][71] ([fdo#103665]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl1/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html
* igt@perf@short-reads:
- shard-kbl: [TIMEOUT][73] ([fdo#112271] / [i915#51]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@perf@short-reads.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl1/igt@perf@short-reads.html
* igt@perf_pmu@busy-vcs1:
- shard-iclb: [SKIP][75] ([fdo#112080]) -> [PASS][76] +12 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@perf_pmu@busy-vcs1.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@perf_pmu@busy-vcs1.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [SKIP][77] ([fdo#112080]) -> [FAIL][78] ([IGT#28]) +1 similar issue
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@gem_tiled_blits@interruptible:
- shard-hsw: [FAIL][79] ([i915#818]) -> [FAIL][80] ([i915#694])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw1/igt@gem_tiled_blits@interruptible.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-hsw7/igt@gem_tiled_blits@interruptible.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
[fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1197]: https://gitlab.freedesktop.org/drm/intel/issues/1197
[i915#1239]: https://gitlab.freedesktop.org/drm/intel/issues/1239
[i915#1241]: https://gitlab.freedesktop.org/drm/intel/issues/1241
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#488]: https://gitlab.freedesktop.org/drm/intel/issues/488
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#51]: https://gitlab.freedesktop.org/drm/intel/issues/51
[i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#72]: https://gitlab.freedesktop.org/drm/intel/issues/72
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#84]: https://gitlab.freedesktop.org/drm/intel/issues/84
[i915#96]: https://gitlab.freedesktop.org/drm/intel/issues/96
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7963 -> Patchwork_16607
CI-20190529: 20190529
CI_DRM_7963: e0d737598eb749378a5dc4ed3dfafc6f79d512cb @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5448: 116020b1f83c1b3994c76882df7f77b6731d78ba @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16607: dbe2fc981e60de0fe193361613c6c8bebb1b78e2 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v3 02/10] ASoC: tegra: add support for CIF programming
From: Jon Hunter @ 2020-02-20 14:30 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-3-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> Audio Client Interface (CIF) is a proprietary interface employed to route
> audio samples through Audio Hub (AHUB) components by inter connecting the
> various modules.
>
> This patch exports an inline function tegra_set_cif() which can be used,
> for now, to program CIF on Tegra210 and later Tegra generations. Later it
> can be extended to include helpers for legacy chips as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/tegra_cif.h | 63 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 sound/soc/tegra/tegra_cif.h
>
> diff --git a/sound/soc/tegra/tegra_cif.h b/sound/soc/tegra/tegra_cif.h
> new file mode 100644
> index 0000000..ecc0850
> --- /dev/null
> +++ b/sound/soc/tegra/tegra_cif.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * tegra_cif.h - TEGRA Audio CIF Programming
> + *
> + * Copyright (c) 2020 NVIDIA CORPORATION. All rights reserved.
> + *
> + */
> +
> +#ifndef __TEGRA_CIF_H__
> +#define __TEGRA_CIF_H__
> +
> +#define TEGRA_ACIF_CTRL_FIFO_TH_SHIFT 24
> +#define TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT 20
> +#define TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT 16
> +#define TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT 12
> +#define TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT 8
> +#define TEGRA_ACIF_CTRL_EXPAND_SHIFT 6
> +#define TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT 4
> +#define TEGRA_ACIF_CTRL_REPLICATE_SHIFT 3
> +#define TEGRA_ACIF_CTRL_TRUNCATE_SHIFT 1
> +#define TEGRA_ACIF_CTRL_MONO_CONV_SHIFT 0
> +
> +/* AUDIO/CLIENT_BITS values */
> +#define TEGRA_ACIF_BITS_8 1
> +#define TEGRA_ACIF_BITS_16 3
> +#define TEGRA_ACIF_BITS_24 5
> +#define TEGRA_ACIF_BITS_32 7
> +
> +#define TEGRA_ACIF_UPDATE_MASK 0x3ffffffb
> +
> +struct tegra_cif_conf {
> + unsigned int threshold;
> + unsigned int audio_ch;
> + unsigned int client_ch;
> + unsigned int audio_bits;
> + unsigned int client_bits;
> + unsigned int expand;
> + unsigned int stereo_conv;
> + unsigned int replicate;
> + unsigned int truncate;
> + unsigned int mono_conv;
> +};
> +
> +static inline void tegra_set_cif(struct regmap *regmap, unsigned int reg,
> + struct tegra_cif_conf *conf)
> +{
> + unsigned int value;
> +
> + value = (conf->threshold << TEGRA_ACIF_CTRL_FIFO_TH_SHIFT) |
> + ((conf->audio_ch - 1) << TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT) |
> + ((conf->client_ch - 1) << TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT) |
> + (conf->audio_bits << TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT) |
> + (conf->client_bits << TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT) |
> + (conf->expand << TEGRA_ACIF_CTRL_EXPAND_SHIFT) |
> + (conf->stereo_conv << TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT) |
> + (conf->replicate << TEGRA_ACIF_CTRL_REPLICATE_SHIFT) |
> + (conf->truncate << TEGRA_ACIF_CTRL_TRUNCATE_SHIFT) |
> + (conf->mono_conv << TEGRA_ACIF_CTRL_MONO_CONV_SHIFT);
> +
> + regmap_update_bits(regmap, reg, TEGRA_ACIF_UPDATE_MASK, value);
> +}
> +
> +#endif
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers!
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints
From: chris hyser @ 2020-02-20 14:30 UTC (permalink / raw)
To: Parth Shah, vincent.guittot, patrick.bellasi, valentin.schneider,
dhaval.giani, dietmar.eggemann
Cc: linux-kernel, peterz, mingo, qais.yousef, pavel, qperret,
David.Laight, pjt, tj
In-Reply-To: <7429e0ae-41ff-e9c4-dd65-3ef1919f5f50@linux.ibm.com>
On 2/20/20 3:50 AM, Parth Shah wrote:
>
>
> On 2/20/20 2:04 PM, Parth Shah wrote:
>>
>>
>> On 2/19/20 11:53 PM, chris hyser wrote:
>>>
>>>
>>> On 2/19/20 9:15 AM, chris hyser wrote:
>>>>
>>>>
>>>> On 2/19/20 5:09 AM, Parth Shah wrote:
>>>>> Hi Chris,
>>>>>
>>>>> On 2/19/20 4:30 AM, chris hyser wrote:
>>>>>> On 2/17/20 3:57 AM, Parth Shah wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 1/16/20 5:32 PM, Parth Shah wrote:
>>>>>>>> This is the 3rd revision of the patch set to introduce
>>>>>>>> latency_{nice/tolerance} as a per task attribute.
>>>>>>>>
>>>>>>>> The previous version can be found at:
>>>>>>>> v1: https://lkml.org/lkml/2019/11/25/151
>>>>>>>> v2: https://lkml.org/lkml/2019/12/8/10
>>>>>>>>
>>>>>>>> Changes in this revision are:
>>>>>>>> v2 -> v3:
>>>>>>>> - This series changes the longer attribute name to "latency_nice" as per
>>>>>>>> the comment from Dietmar Eggemann
>>>>>>>> https://lkml.org/lkml/2019/12/5/394
>>>>>>>> v1 -> v2:
>>>>>>>> - Addressed comments from Qais Yousef
>>>>>>>> - As per suggestion from Dietmar, moved content from newly created
>>>>>>>> include/linux/sched/latency_tolerance.h to kernel/sched/sched.h
>>>>>>>> - Extend sched_setattr() to support latency_tolerance in tools
>>>>>>>> headers UAPI
>>>>>>>>
>>>>>>>>
>>>>>>>> Introduction:
>>>>>>>> ==============
>>>>>>>> This patch series introduces a new per-task attribute latency_nice to
>>>>>>>> provide the scheduler hints about the latency requirements of the
>>>>>>>> task [1].
>>>>>>>>
>>>>>>>> Latency_nice is a ranged attribute of a task with the value ranging
>>>>>>>> from [-20, 19] both inclusive which makes it align with the task nice
>>>>>>>> value.
>>>>>>>>
>>>>>>>> The value should provide scheduler hints about the relative latency
>>>>>>>> requirements of tasks, meaning the task with "latency_nice = -20"
>>>>>>>> should have lower latency requirements than compared to those tasks with
>>>>>>>> higher values. Similarly a task with "latency_nice = 19" can have higher
>>>>>>>> latency and hence such tasks may not care much about latency.
>>>>>>>>
>>>>>>>> The default value is set to 0. The usecases discussed below can use this
>>>>>>>> range of [-20, 19] for latency_nice for the specific purpose. This
>>>>>>>> patch does not implement any use cases for such attribute so that any
>>>>>>>> change in naming or range does not affect much to the other (future)
>>>>>>>> patches using this. The actual use of latency_nice during task wakeup
>>>>>>>> and load-balancing is yet to be coded for each of those usecases.
>>>>>>>>
>>>>>>>> As per my view, this defined attribute can be used in following ways
>>>>>>>> for a
>>>>>>>> some of the usecases:
>>>>>>>> 1 Reduce search scan time for select_idle_cpu():
>>>>>>>> - Reduce search scans for finding idle CPU for a waking task with lower
>>>>>>>> latency_nice values.
>>>>>>>>
>>>>>>>> 2 TurboSched:
>>>>>>>> - Classify the tasks with higher latency_nice values as a small
>>>>>>>> background task given that its historic utilization is very low, for
>>>>>>>> which the scheduler can search for more number of cores to do task
>>>>>>>> packing. A task with a latency_nice >= some_threshold (e.g, == 19)
>>>>>>>> and util <= 12.5% can be background tasks.
>>>>>>>>
>>>>>>>> 3 Optimize AVX512 based workload:
>>>>>>>> - Bias scheduler to not put a task having (latency_nice == -20) on a
>>>>>>>> core occupying AVX512 based workload.
>>>>>>>>
>>>>>>>>
>>>>>>>> Series Organization:
>>>>>>>> ====================
>>>>>>>> - Patch 1: Add new attribute latency_nice to task_struct.
>>>>>>>> - Patch 2: Clone parent task's attribute to the child task on fork
>>>>>>>> - Patch 3: Add support for sched_{set,get}attr syscall to modify
>>>>>>>> latency_nice of the task
>>>>>>>>
>>>>>>>>
>>>>>>>> The patch series can be applied on tip/sched/core at the
>>>>>>>> commit 804d402fb6f6 ("sched/rt: Make RT capacity-aware")
>>>>>>>>
>>>>>>>>
>>>>>>>> References:
>>>>>>>> ============
>>>>>>>> [1]. Usecases for the per-task latency-nice attribute,
>>>>>>>> https://lkml.org/lkml/2019/9/30/215
>>>>>>>> [2]. Task Latency-nice, "Subhra Mazumdar",
>>>>>>>> https://lkml.org/lkml/2019/8/30/829
>>>>>>>> [3]. Introduce per-task latency_tolerance for scheduler hints,
>>>>>>>> https://lkml.org/lkml/2019/12/8/10
>>>>>>>>
>>>>>>>>
>>>>>>>> Parth Shah (3):
>>>>>>>> sched: Introduce latency-nice as a per-task attribute
>>>>>>>> sched/core: Propagate parent task's latency requirements to the
>>>>>>>> child
>>>>>>>> task
>>>>>>>> sched: Allow sched_{get,set}attr to change latency_nice of the task
>>>>>>>>
>>>>>>>> include/linux/sched.h | 1 +
>>>>>>>> include/uapi/linux/sched.h | 4 +++-
>>>>>>>> include/uapi/linux/sched/types.h | 19 +++++++++++++++++++
>>>>>>>> kernel/sched/core.c | 21 +++++++++++++++++++++
>>>>>>>> kernel/sched/sched.h | 18 ++++++++++++++++++
>>>>>>>> tools/include/uapi/linux/sched.h | 4 +++-
>>>>>>>> 6 files changed, 65 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>
>>>>>>> Its been a long time and few revisions since the beginning of the
>>>>>>> discussion around the latency-nice. Hence thought of asking if there
>>>>>>> is/are
>>>>>>> any further work that needs to be done for adding latency-nice
>>>>>>> attribute or
>>>>>>> am I missing any piece in here?
>>>>>>
>>>>>> All, I was asked to take a look at the original latency_nice patchset.
>>>>>> First, to clarify objectives, Oracle is not interested in trading
>>>>>> throughput for latency. What we found is that the DB has specific tasks
>>>>>> which do very little but need to do this as absolutely quickly as
>>>>>> possible,
>>>>>> ie extreme latency sensitivity. Second, the key to latency reduction in
>>>>>> the
>>>>>> task wakeup path seems to be limiting variations of "idle cpu" search. The
>>>>>> latter particularly interests me as an example of "platform size based
>>>>>> latency" which I believe to be important given all the varying size VMs
>>>>>> and
>>>>>> containers.
>>>>>>
>>>>>> Parth, I've been using your v3 patchset as the basis of an investigation
>>>>>> into the measurable effects of short-circuiting this search. I'm not quite
>>>>>> ready to put anything out, but the patchset is working well. The only
>>>>>
>>>>> That's a good news as you are able to get a usecase of this patch-set.
>>>>>
>>>>>> feedback I have is that currently non-root can set the value negative
>>>>>> which
>>>>>> is inconsistent with 'nice' and I would think a security hole.
>>>>>>
>>>>>
>>>>> I would assume you mean 'latency_nice' here.
>>>>>
>>>>> From my testing, I was not able to set values for any root owned task's
>>>>> latency_nice value by the non-root user. Also, my patch-set just piggybacks
>>>>> on the already existing sched_setattr syscall and hence it should not allow
>>>>> non-root user to do any modifications. Can you confirm this by changing
>>>>> nice (renice) value of a root task from non-root user.
>>>>>
>>>>> I have done the sanity check in the code and thinking where it could
>>>>> possibly have gone wrong. So, can you please specify what values were you
>>>>> able to set outside the [-20, 19] range?
>>>>
>>>> The checks prevent being outside that range. But negative numbers -20 to
>>>> -1 did not need root. Let me dig some more. I verified this explicitly
>>>> before sending the email so something is up.
>>>
>>> I went digging. This is absolutely repeatable. I checked that I do not
>>> unknowingly have CAP_SYS_NICE as a user. So first, are we tying
>>> latency_nice to CAP_SYS_NICE? Seems like a reasonable thing, but not sure I
>>> saw this stated anywhere. Second, the only capability checked in
>>> __sched_setscheduler() in the patch I have is CAP_SYS_NICE and those checks
>>> will not return a -EPERM for a negative latency_tolerance (in the code, aka
>>> latency_nice). Do I have the correct version of the code? Am I missing
>>> something?
>>
>> You are right. I have not added permission checks for setting the
>> latency_nice value. For the task_nice, non-root user has no permission to
>> set the value lower than the current value which is not the case with the
>> latency_nice.
>>
>> In order to align with the permission checks like task_nice, I will add the
>> check similar to task_nice and send out the v4 of the series soon.
>>
>>
>> Thanks for pointing out.
>> - Parth
>>
>
> The below diff works out well enough in-order to align permission checks
> with NICE.
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 2bfcff5623f9..ef4a397c9170 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4878,6 +4878,10 @@ static int __sched_setscheduler(struct task_struct *p,
> return -EINVAL;
> if (attr->sched_latency_nice < MIN_LATENCY_NICE)
> return -EINVAL;
> + /* Use the same security checks as NICE */
> + if (attr->sched_latency_nice < p->latency_nice &&
> + !can_nice(p, attr->sched_latency_nice))
> + return -EPERM;
> }
>
> if (pi)
>
> With the above in effect,
> A non-root user can only increase the value upto +19, and once increased
> cannot be decreased. e.g., a user once sets the value latency_nice = 19,
> the same user cannot set the value latency_nice = 18. This is the same
> effect as with NICE.
>
> Is such permission checks required?
>
> Unlike NICE, we are going to use latency_nice for scheduler hints only, and
> so won't it make more sense to allow a user to increase/decrease the values
> of their owned tasks?
Whether called a hint or not, it is a trade-off to reduce latency of select tasks at the expense of the throughput of
the other tasks in the the system. If any of the other tasks belong to other users, you would presumably require permission.
-chrish
^ permalink raw reply
* Re: [PATCH v3 02/10] ASoC: tegra: add support for CIF programming
From: Jon Hunter @ 2020-02-20 14:30 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-3-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> Audio Client Interface (CIF) is a proprietary interface employed to route
> audio samples through Audio Hub (AHUB) components by inter connecting the
> various modules.
>
> This patch exports an inline function tegra_set_cif() which can be used,
> for now, to program CIF on Tegra210 and later Tegra generations. Later it
> can be extended to include helpers for legacy chips as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/tegra_cif.h | 63 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 sound/soc/tegra/tegra_cif.h
>
> diff --git a/sound/soc/tegra/tegra_cif.h b/sound/soc/tegra/tegra_cif.h
> new file mode 100644
> index 0000000..ecc0850
> --- /dev/null
> +++ b/sound/soc/tegra/tegra_cif.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * tegra_cif.h - TEGRA Audio CIF Programming
> + *
> + * Copyright (c) 2020 NVIDIA CORPORATION. All rights reserved.
> + *
> + */
> +
> +#ifndef __TEGRA_CIF_H__
> +#define __TEGRA_CIF_H__
> +
> +#define TEGRA_ACIF_CTRL_FIFO_TH_SHIFT 24
> +#define TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT 20
> +#define TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT 16
> +#define TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT 12
> +#define TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT 8
> +#define TEGRA_ACIF_CTRL_EXPAND_SHIFT 6
> +#define TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT 4
> +#define TEGRA_ACIF_CTRL_REPLICATE_SHIFT 3
> +#define TEGRA_ACIF_CTRL_TRUNCATE_SHIFT 1
> +#define TEGRA_ACIF_CTRL_MONO_CONV_SHIFT 0
> +
> +/* AUDIO/CLIENT_BITS values */
> +#define TEGRA_ACIF_BITS_8 1
> +#define TEGRA_ACIF_BITS_16 3
> +#define TEGRA_ACIF_BITS_24 5
> +#define TEGRA_ACIF_BITS_32 7
> +
> +#define TEGRA_ACIF_UPDATE_MASK 0x3ffffffb
> +
> +struct tegra_cif_conf {
> + unsigned int threshold;
> + unsigned int audio_ch;
> + unsigned int client_ch;
> + unsigned int audio_bits;
> + unsigned int client_bits;
> + unsigned int expand;
> + unsigned int stereo_conv;
> + unsigned int replicate;
> + unsigned int truncate;
> + unsigned int mono_conv;
> +};
> +
> +static inline void tegra_set_cif(struct regmap *regmap, unsigned int reg,
> + struct tegra_cif_conf *conf)
> +{
> + unsigned int value;
> +
> + value = (conf->threshold << TEGRA_ACIF_CTRL_FIFO_TH_SHIFT) |
> + ((conf->audio_ch - 1) << TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT) |
> + ((conf->client_ch - 1) << TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT) |
> + (conf->audio_bits << TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT) |
> + (conf->client_bits << TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT) |
> + (conf->expand << TEGRA_ACIF_CTRL_EXPAND_SHIFT) |
> + (conf->stereo_conv << TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT) |
> + (conf->replicate << TEGRA_ACIF_CTRL_REPLICATE_SHIFT) |
> + (conf->truncate << TEGRA_ACIF_CTRL_TRUNCATE_SHIFT) |
> + (conf->mono_conv << TEGRA_ACIF_CTRL_MONO_CONV_SHIFT);
> +
> + regmap_update_bits(regmap, reg, TEGRA_ACIF_UPDATE_MASK, value);
> +}
> +
> +#endif
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers!
Jon
--
nvpublic
^ permalink raw reply
* [igt-dev] [PATCH] Reduce Docker images size
From: Ramotowski, Maciej @ 2020-02-20 14:32 UTC (permalink / raw)
To: igt-dev@lists.freedesktop.org
Cc: Ramotowski, Maciej, Oleg Vasilev, Latvala, Petri
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Oleg Vasilev <oleg.vasilev@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Maciej Ramotowski <maciej.ramotowski@intel.com>
---
Dockerfile.build-debian | 39 ++++++++----------
Dockerfile.build-debian-arm64 | 68 +++++++++++++++-----------------
Dockerfile.build-debian-armhf | 67 +++++++++++++++----------------
Dockerfile.build-debian-minimal | 44 ++++++++++-----------
Dockerfile.build-debian-mips | 70 +++++++++++++++------------------
5 files changed, 132 insertions(+), 156 deletions(-)
diff --git a/Dockerfile.build-debian b/Dockerfile.build-debian
index b143a532..6cf7a1f0 100644
--- a/Dockerfile.build-debian
+++ b/Dockerfile.build-debian
@@ -7,25 +7,20 @@ FROM $CI_REGISTRY_IMAGE/build-debian-minimal:commit-$CI_COMMIT_SHA
# just few extra dependencies for building IGT with all the optional components
# enabled
-RUN apt-get update
-RUN apt-get install -y \
- libunwind-dev \
- libgsl-dev \
- libasound2-dev \
- libxmlrpc-core-c3-dev \
- libjson-c-dev \
- libcurl4-openssl-dev \
- python-docutils \
- valgrind \
- peg \
- libdrm-intel1
-
-# autotools build deps
-RUN apt-get install -y \
- autoconf \
- automake \
- xutils-dev \
- libtool \
- make
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ autoconf \
+ automake \
+ libasound2-dev \
+ libcurl4-openssl-dev \
+ libdrm-intel1 \
+ libgsl-dev \
+ libjson-c-dev \
+ libtool \
+ libunwind-dev \
+ libxmlrpc-core-c3-dev \
+ make \
+ peg \
+ python-docutils \
+ valgrind \
+ xutils-dev \
+ && rm -rf /var/lib/apt/lists/*
diff --git a/Dockerfile.build-debian-arm64 b/Dockerfile.build-debian-arm64
index 573c7096..924432bd 100644
--- a/Dockerfile.build-debian-arm64
+++ b/Dockerfile.build-debian-arm64
@@ -1,40 +1,34 @@
FROM debian:buster
-RUN apt-get update
-RUN apt-get install -y \
- flex \
- bison \
- pkg-config \
- x11proto-dri2-dev \
- python-docutils \
- valgrind \
- peg
-
RUN dpkg --add-architecture arm64
-RUN apt-get update
-RUN apt-get install -y \
- gcc-aarch64-linux-gnu \
- libatomic1:arm64 \
- libpciaccess-dev:arm64 \
- libkmod-dev:arm64 \
- libprocps-dev:arm64 \
- libunwind-dev:arm64 \
- libdw-dev:arm64 \
- zlib1g-dev:arm64 \
- liblzma-dev:arm64 \
- libcairo-dev:arm64 \
- libpixman-1-dev:arm64 \
- libudev-dev:arm64 \
- libgsl-dev:arm64 \
- libasound2-dev:arm64 \
- libjson-c-dev:arm64 \
- libcurl4-openssl-dev:arm64 \
- libxrandr-dev:arm64 \
- libxv-dev:arm64 \
- meson \
- libdrm-dev:arm64 \
- qemu-user \
- qemu-user-static
-
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ bison \
+ flex \
+ gcc-aarch64-linux-gnu \
+ libasound2-dev:arm64 \
+ libatomic1:arm64 \
+ libcairo-dev:arm64 \
+ libcurl4-openssl-dev:arm64 \
+ libdrm-dev:arm64 \
+ libdw-dev:arm64 \
+ libgsl-dev:arm64 \
+ libjson-c-dev:arm64 \
+ libkmod-dev:arm64 \
+ liblzma-dev:arm64 \
+ libpciaccess-dev:arm64 \
+ libpixman-1-dev:arm64 \
+ libprocps-dev:arm64 \
+ libudev-dev:arm64 \
+ libunwind-dev:arm64 \
+ libxrandr-dev:arm64 \
+ libxv-dev:arm64 \
+ meson \
+ peg \
+ pkg-config \
+ python-docutils \
+ qemu-user \
+ qemu-user-static \
+ valgrind \
+ x11proto-dri2-dev \
+ zlib1g-dev:arm64 \
+ && rm -rf /var/lib/apt/lists/*
diff --git a/Dockerfile.build-debian-armhf b/Dockerfile.build-debian-armhf
index 737ca364..3752dc91 100644
--- a/Dockerfile.build-debian-armhf
+++ b/Dockerfile.build-debian-armhf
@@ -1,39 +1,34 @@
FROM debian:buster
-RUN apt-get update
-RUN apt-get install -y \
- flex \
- bison \
- pkg-config \
- x11proto-dri2-dev \
- python-docutils \
- valgrind \
- peg
-
RUN dpkg --add-architecture armhf
-RUN apt-get update
-RUN apt-get install -y \
- gcc-arm-linux-gnueabihf \
- libatomic1:armhf \
- libpciaccess-dev:armhf \
- libkmod-dev:armhf \
- libprocps-dev:armhf \
- libunwind-dev:armhf \
- libdw-dev:armhf \
- zlib1g-dev:armhf \
- liblzma-dev:armhf \
- libcairo-dev:armhf \
- libpixman-1-dev:armhf \
- libudev-dev:armhf \
- libgsl-dev:armhf \
- libasound2-dev:armhf \
- libjson-c-dev:armhf \
- libcurl4-openssl-dev:armhf \
- libxrandr-dev:armhf \
- libxv-dev:armhf \
- meson \
- libdrm-dev:armhf \
- qemu-user \
- qemu-user-static
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ bison \
+ flex \
+ gcc-arm-linux-gnueabihf \
+ libasound2-dev:armhf \
+ libatomic1:armhf \
+ libcairo-dev:armhf \
+ libcurl4-openssl-dev:armhf \
+ libdrm-dev:armhf \
+ libdw-dev:armhf \
+ libgsl-dev:armhf \
+ libjson-c-dev:armhf \
+ libkmod-dev:armhf \
+ liblzma-dev:armhf \
+ libpciaccess-dev:armhf \
+ libpixman-1-dev:armhf \
+ libprocps-dev:armhf \
+ libudev-dev:armhf \
+ libunwind-dev:armhf \
+ libxrandr-dev:armhf \
+ libxv-dev:armhf \
+ meson \
+ peg \
+ pkg-config \
+ python-docutils \
+ qemu-user \
+ qemu-user-static \
+ valgrind \
+ x11proto-dri2-dev \
+ zlib1g-dev:armhf \
+ && rm -rf /var/lib/apt/lists/*
diff --git a/Dockerfile.build-debian-minimal b/Dockerfile.build-debian-minimal
index 64edf4b4..d0756be5 100644
--- a/Dockerfile.build-debian-minimal
+++ b/Dockerfile.build-debian-minimal
@@ -1,25 +1,23 @@
FROM debian:buster
-RUN apt-get update
-RUN apt-get install -y \
- gcc \
- flex \
- bison \
- pkg-config \
- libatomic1 \
- libpciaccess-dev \
- libkmod-dev \
- libprocps-dev \
- libdw-dev \
- zlib1g-dev \
- liblzma-dev \
- libcairo-dev \
- libpixman-1-dev \
- libudev-dev \
- libxrandr-dev \
- libxv-dev \
- x11proto-dri2-dev \
- meson \
- libdrm-dev
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ bison \
+ flex \
+ gcc \
+ libatomic1 \
+ libcairo-dev \
+ libdrm-dev \
+ libdw-dev \
+ libkmod-dev \
+ liblzma-dev \
+ libpciaccess-dev \
+ libpixman-1-dev \
+ libprocps-dev \
+ libudev-dev \
+ libxrandr-dev \
+ libxv-dev \
+ meson \
+ pkg-config \
+ x11proto-dri2-dev \
+ zlib1g-dev \
+ && rm -rf /var/lib/apt/lists/*
diff --git a/Dockerfile.build-debian-mips b/Dockerfile.build-debian-mips
index 7e4bacdf..e52d403b 100644
--- a/Dockerfile.build-debian-mips
+++ b/Dockerfile.build-debian-mips
@@ -2,42 +2,36 @@
# https://bugs.debian.org/932725
FROM debian:stretch-backports
-RUN apt-get update
-RUN apt-get install -y \
- flex \
- bison \
- pkg-config \
- x11proto-dri2-dev \
- python-docutils \
- valgrind \
- peg
-
RUN dpkg --add-architecture mips
-RUN apt-get update
-RUN apt-get install -y \
- gcc-mips-linux-gnu \
- libatomic1:mips \
- libpciaccess-dev:mips \
- libkmod-dev:mips \
- libprocps-dev:mips \
- libunwind-dev:mips \
- libdw-dev:mips \
- zlib1g-dev:mips \
- liblzma-dev:mips \
- libcairo-dev:mips \
- libpixman-1-dev:mips \
- libudev-dev:mips \
- libgsl-dev:mips \
- libasound2-dev:mips \
- libjson-c-dev:mips \
- libcurl4-openssl-dev:mips \
- libxrandr-dev:mips \
- libxv-dev:mips
-
-RUN apt-get install -t stretch-backports -y \
- meson \
- libdrm-dev:mips \
- qemu-user \
- qemu-user-static
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ bison \
+ flex \
+ gcc-mips-linux-gnu \
+ libasound2-dev:mips \
+ libatomic1:mips \
+ libcairo-dev:mips \
+ libcurl4-openssl-dev:mips \
+ libdw-dev:mips \
+ libgsl-dev:mips \
+ libjson-c-dev:mips \
+ libkmod-dev:mips \
+ liblzma-dev:mips \
+ libpciaccess-dev:mips \
+ libpixman-1-dev:mips \
+ libprocps-dev:mips \
+ libudev-dev:mips \
+ libunwind-dev:mips \
+ libxrandr-dev:mips \
+ libxv-dev:mips \
+ peg \
+ pkg-config \
+ python-docutils \
+ valgrind \
+ x11proto-dri2-dev \
+ zlib1g-dev:mips \
+ && apt-get install -t stretch-backports -y \
+ libdrm-dev:mips \
+ meson \
+ qemu-user \
+ qemu-user-static \
+ && rm -rf /var/lib/apt/lists/*
--
2.17.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* [PATCH] env: ti: boot: Fix Android boot on AM57x EVM
From: Eugeniu Rosca @ 2020-02-20 14:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200219182752.27392-1-joe.skb7@gmail.com>
Hi Sam,
On Wed, Feb 19, 2020 at 08:27:52PM +0200, Sam Protsenko wrote:
> When applying DTBO on top of DTB (with "fdt apply" command) on AM57x EVM
> board, there is not enough memory reserved in RAM for DTB blob. Hence,
> DTBO can't be merged in DTB. It leads to inability to boot Android with
> next error message:
>
> failed on fdt_overlay_apply(): FDT_ERR_NOSPACE
>
> To overcome that issue let's provide 1 MiB of space to keep DTB and all
> merged DTBO blobs. To do so, "length" parameter should be specified for
> "fdt addr" command:
>
> => fdt addr $fdtaddr 0x100000
I am not an everyday user of this platform, hence curious what are the
usual sizes of DTB and DTBO files employed in Android booting?
For comparison, below are the sizes of R-Car3 DTB (Linux v5.6-rc2):
$ du -sh arch/arm64/boot/dts/renesas/r8a779*dtb | sort -n
32K arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dtb
32K arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dtb
44K arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb
52K arch/arm64/boot/dts/renesas/r8a77965-ulcb.dtb
60K arch/arm64/boot/dts/renesas/r8a77960-ulcb.dtb
60K arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dtb
60K arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dtb
60K arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dtb
64K arch/arm64/boot/dts/renesas/r8a77960-salvator-x.dtb
64K arch/arm64/boot/dts/renesas/r8a77960-salvator-xs.dtb
64K arch/arm64/boot/dts/renesas/r8a77960-ulcb-kf.dtb
68K arch/arm64/boot/dts/renesas/r8a77950-ulcb.dtb
68K arch/arm64/boot/dts/renesas/r8a77951-ulcb.dtb
72K arch/arm64/boot/dts/renesas/r8a77950-salvator-x.dtb
72K arch/arm64/boot/dts/renesas/r8a77950-ulcb-kf.dtb
72K arch/arm64/boot/dts/renesas/r8a77951-salvator-x.dtb
72K arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb
72K arch/arm64/boot/dts/renesas/r8a77951-ulcb-kf.dtb
FWIW based on the above values, Renesas scripts reserve 512K for DTB.
>
> Also add size variables to 'adtimg' command invocations, to avoid
> cluttering the console with DTBO blob sizes.
Looks good to me.
>
> Signed-off-by: Sam Protsenko <joe.skb7@gmail.com>
Reviewed-by: Eugeniu Rosca <rosca.eugeniu@gmail.com>
--
Best Regards
Eugeniu Rosca
^ permalink raw reply
* [MPTCP] [PATCH v3 0/6] mptcp: update mptcp ack sequence from work queue
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
V3. No changes since v2, I only updated commit messages in
patches 1, 2, 3 and 6.
I think we should try to avoid needless squashing and keep
these as-is for now. We can always condense some of this later
on in case we need to reduce number of individual patches for some
reason.
^ permalink raw reply
* [MPTCP] [PATCH v3 1/6] mptcp: add and use mptcp_data_ready helper
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]
allows us to schedule the work queue to drain the ssk receive queue in
a followup patch.
This is needed to avoid sending all-to-pessimistic mptcp-level
acknowledgements. At this time, the ack_seq is what was last read by
userspace instead of the highest in-sequence number queued for reading.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 8 ++++++++
net/mptcp/protocol.h | 1 +
net/mptcp/subflow.c | 14 ++++----------
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 47b3c4afdc87..84204129e1d3 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -156,6 +156,14 @@ void mptcp_subflow_eof(struct sock *sk)
sock_hold(sk);
}
+void mptcp_data_ready(struct sock *sk)
+{
+ struct mptcp_sock *msk = mptcp_sk(sk);
+
+ set_bit(MPTCP_DATA_READY, &msk->flags);
+ sk->sk_data_ready(sk);
+}
+
static void mptcp_stop_timer(struct sock *sk)
{
struct inet_connection_sock *icsk = inet_csk(sk);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 3fbb33deb764..95b0ade75771 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -317,6 +317,7 @@ void mptcp_finish_connect(struct sock *sk);
void mptcp_subflow_eof(struct sock *sk);
bool mptcp_finish_join(struct sock *sk);
void mptcp_data_acked(struct sock *sk);
+void mptcp_data_ready(struct sock *sk);
int mptcp_token_new_request(struct request_sock *req);
void mptcp_token_destroy_request(u32 token);
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 547d5ffef070..fbff5dc39575 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -723,11 +723,8 @@ static void subflow_data_ready(struct sock *sk)
return;
}
- if (mptcp_subflow_data_available(sk)) {
- set_bit(MPTCP_DATA_READY, &mptcp_sk(parent)->flags);
-
- parent->sk_data_ready(parent);
- }
+ if (mptcp_subflow_data_available(sk))
+ mptcp_data_ready(parent);
}
static void subflow_write_space(struct sock *sk)
@@ -916,11 +913,8 @@ static void subflow_state_change(struct sock *sk)
* a fin packet carrying a DSS can be unnoticed if we don't trigger
* the data available machinery here.
*/
- if (parent && subflow->mp_capable && mptcp_subflow_data_available(sk)) {
- set_bit(MPTCP_DATA_READY, &mptcp_sk(parent)->flags);
-
- parent->sk_data_ready(parent);
- }
+ if (parent && subflow->mp_capable && mptcp_subflow_data_available(sk))
+ mptcp_data_ready(parent);
if (parent && !(parent->sk_shutdown & RCV_SHUTDOWN) &&
!subflow->rx_eof && subflow_is_done(sk)) {
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 2/6] mptcp: update mptcp ack sequence from work queue
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 9967 bytes --]
This adds a new worker flag to indicate when the work queue should
drain a subflow socket.
skbs on the subflow socket are then placed on the mptcp socket receive
queue (which was not used so far).
This allows us to announce the correct mptcp ack sequence in the tcp
acks that we send back to the peer, even when the application does not
call recv() on the mptcp socket for some time.
We still wake userspace tasks waiting for POLLIN immediately:
If the mptcp level receive queue is empty (because the work queue is
still pending) it can be filled from in-sequence subflow sockets at
recv time.
Without this, when userspace is not reading data, all the mptcp-level
acks contain the ack_seq from the last time userspace read data rather
than the most recent in-sequence value. This causes pointless
retransmissions for data that is already queued.
The skb_orphan when moving skbs from subflow to mptcp level is needed,
because the destructor (sock_rfree) relies on skb->sk (ssk!) lock
being taken.
Followup patch will add needed rmem accouting for the moved skbs.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 231 ++++++++++++++++++++++++++++++-------------
net/mptcp/protocol.h | 1 +
2 files changed, 164 insertions(+), 68 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 84204129e1d3..85d7f73ca804 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -34,6 +34,12 @@ struct mptcp6_sock {
static struct percpu_counter mptcp_sockets_allocated;
+struct mptcp_skb_cb {
+ u32 offset;
+};
+
+#define MPTCP_SKB_CB(__skb) ((struct mptcp_skb_cb *)&((__skb)->cb[0]))
+
/* If msk has an initial subflow socket, and the MP_CAPABLE handshake has not
* completed yet or has failed, return the subflow socket.
* Otherwise return NULL.
@@ -162,6 +168,13 @@ void mptcp_data_ready(struct sock *sk)
set_bit(MPTCP_DATA_READY, &msk->flags);
sk->sk_data_ready(sk);
+
+ if (test_and_set_bit(MPTCP_WORK_DATA_READY, &msk->flags))
+ return;
+
+ sock_hold(sk);
+ if (!schedule_work(&msk->rtx_work))
+ sock_put(sk);
}
static void mptcp_stop_timer(struct sock *sk)
@@ -641,19 +654,134 @@ static void mptcp_wait_data(struct sock *sk, long *timeo)
remove_wait_queue(sk_sleep(sk), &wait);
}
+static int __mptcp_recvmsg_mskq(struct mptcp_sock *msk,
+ struct msghdr *msg,
+ size_t len)
+{
+ struct sock *sk = (struct sock *)msk;
+ struct sk_buff *skb;
+ int copied = 0;
+
+ while ((skb = skb_peek(&sk->sk_receive_queue)) != NULL) {
+ u32 offset = MPTCP_SKB_CB(skb)->offset;
+ u32 data_len = skb->len - offset;
+ u32 count = min_t(size_t, len - copied, data_len);
+ int err;
+
+ err = skb_copy_datagram_msg(skb, offset, msg, count);
+ if (unlikely(err < 0)) {
+ if (!copied)
+ return err;
+ break;
+ }
+
+ copied += count;
+
+ if (count < data_len) {
+ MPTCP_SKB_CB(skb)->offset += count;
+ break;
+ }
+
+ __skb_unlink(skb, &sk->sk_receive_queue);
+ __kfree_skb(skb);
+
+ if (copied >= len)
+ break;
+ }
+
+ return copied;
+}
+
+static void __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
+ struct sk_buff *skb,
+ unsigned int offset, size_t copy_len)
+{
+ struct sock *sk = (struct sock *)msk;
+
+ __skb_unlink(skb, &ssk->sk_receive_queue);
+ skb_orphan(skb);
+ __skb_queue_tail(&sk->sk_receive_queue, skb);
+
+ msk->ack_seq += copy_len;
+ MPTCP_SKB_CB(skb)->offset = offset;
+}
+
+static bool __mptcp_move_skbs(struct mptcp_sock *msk)
+{
+ struct sock *sk = &msk->sk.icsk_inet.sk;
+ unsigned int moved = 0;
+ bool done = false;
+
+ do {
+ struct mptcp_subflow_context *subflow;
+ struct sock *ssk;
+ bool more_data_avail;
+ struct tcp_sock *tp;
+
+ ssk = mptcp_subflow_recv_lookup(msk);
+ if (!ssk)
+ break;
+
+ subflow = mptcp_subflow_ctx(ssk);
+
+ lock_sock(ssk);
+
+ tp = tcp_sk(ssk);
+ do {
+ u32 map_remaining, offset;
+ u32 seq = tp->copied_seq;
+ struct sk_buff *skb;
+ bool fin;
+
+ /* try to move as much data as available */
+ map_remaining = subflow->map_data_len -
+ mptcp_subflow_get_map_offset(subflow);
+
+ skb = skb_peek(&ssk->sk_receive_queue);
+ if (!skb)
+ break;
+
+ offset = seq - TCP_SKB_CB(skb)->seq;
+ fin = TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN;
+ if (fin) {
+ done = true;
+ seq++;
+ }
+
+ if (offset < skb->len) {
+ size_t len = skb->len - offset;
+
+ if (tp->urg_data)
+ done = true;
+
+ __mptcp_move_skb(msk, ssk, skb, offset, len);
+ seq += len;
+ moved += len;
+
+ if (WARN_ON_ONCE(map_remaining < len))
+ break;
+ } else {
+ WARN_ON_ONCE(!fin);
+ sk_eat_skb(sk, skb);
+ done = true;
+ }
+
+ WRITE_ONCE(tp->copied_seq, seq);
+ more_data_avail = mptcp_subflow_data_available(ssk);
+ } while (more_data_avail);
+
+ release_sock(ssk);
+ } while (!done);
+
+ return moved > 0;
+}
+
+
static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
int nonblock, int flags, int *addr_len)
{
struct mptcp_sock *msk = mptcp_sk(sk);
- struct mptcp_subflow_context *subflow;
- bool more_data_avail = false;
- struct mptcp_read_arg arg;
- read_descriptor_t desc;
- bool wait_data = false;
struct socket *ssock;
- struct tcp_sock *tp;
- bool done = false;
- struct sock *ssk;
int copied = 0;
int target;
long timeo;
@@ -671,66 +799,27 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
return copied;
}
- arg.msg = msg;
- desc.arg.data = &arg;
- desc.error = 0;
-
timeo = sock_rcvtimeo(sk, nonblock);
len = min_t(size_t, len, INT_MAX);
target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);
__mptcp_flush_join_list(msk);
- while (!done) {
- u32 map_remaining;
+ while (len > (size_t)copied) {
int bytes_read;
- ssk = mptcp_subflow_recv_lookup(msk);
- pr_debug("msk=%p ssk=%p", msk, ssk);
- if (!ssk)
- goto wait_for_data;
+ bytes_read = __mptcp_recvmsg_mskq(msk, msg, len - copied);
+ if (unlikely(bytes_read < 0)) {
+ if (!copied)
+ copied = bytes_read;
+ goto out_err;
+ }
- subflow = mptcp_subflow_ctx(ssk);
- tp = tcp_sk(ssk);
+ copied += bytes_read;
- lock_sock(ssk);
- do {
- /* try to read as much data as available */
- map_remaining = subflow->map_data_len -
- mptcp_subflow_get_map_offset(subflow);
- desc.count = min_t(size_t, len - copied, map_remaining);
- pr_debug("reading %zu bytes, copied %d", desc.count,
- copied);
- bytes_read = tcp_read_sock(ssk, &desc,
- mptcp_read_actor);
- if (bytes_read < 0) {
- if (!copied)
- copied = bytes_read;
- done = true;
- goto next;
- }
-
- pr_debug("msk ack_seq=%llx -> %llx", msk->ack_seq,
- msk->ack_seq + bytes_read);
- msk->ack_seq += bytes_read;
- copied += bytes_read;
- if (copied >= len) {
- done = true;
- goto next;
- }
- if (tp->urg_data && tp->urg_seq == tp->copied_seq) {
- pr_err("Urgent data present, cannot proceed");
- done = true;
- goto next;
- }
-next:
- more_data_avail = mptcp_subflow_data_available(ssk);
- } while (more_data_avail && !done);
- release_sock(ssk);
- continue;
-
-wait_for_data:
- more_data_avail = false;
+ if (skb_queue_empty(&sk->sk_receive_queue) &&
+ __mptcp_move_skbs(msk))
+ continue;
/* only the master socket status is relevant here. The exit
* conditions mirror closely tcp_recvmsg()
@@ -771,26 +860,25 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
}
pr_debug("block timeout %ld", timeo);
- wait_data = true;
mptcp_wait_data(sk, &timeo);
if (unlikely(__mptcp_tcp_fallback(msk)))
goto fallback;
}
- if (more_data_avail) {
- if (!test_bit(MPTCP_DATA_READY, &msk->flags))
- set_bit(MPTCP_DATA_READY, &msk->flags);
- } else if (!wait_data) {
+ if (skb_queue_empty(&sk->sk_receive_queue)) {
+ /* entire backlog drained, clear DATA_READY. */
clear_bit(MPTCP_DATA_READY, &msk->flags);
- /* .. race-breaker: ssk might get new data after last
- * data_available() returns false.
+ /* .. race-breaker: ssk might have gotten new data
+ * after last __mptcp_move_skbs() returned false.
*/
- ssk = mptcp_subflow_recv_lookup(msk);
- if (unlikely(ssk))
+ if (unlikely(__mptcp_move_skbs(msk)))
set_bit(MPTCP_DATA_READY, &msk->flags);
+ } else if (unlikely(!test_bit(MPTCP_DATA_READY, &msk->flags))) {
+ /* data to read but mptcp_wait_data() cleared DATA_READY */
+ set_bit(MPTCP_DATA_READY, &msk->flags);
}
-
+out_err:
release_sock(sk);
return copied;
}
@@ -921,6 +1009,9 @@ static void mptcp_worker(struct work_struct *work)
lock_sock(sk);
mptcp_clean_una(sk);
+ if (test_and_clear_bit(MPTCP_WORK_DATA_READY, &msk->flags))
+ __mptcp_move_skbs(msk);
+
if (test_and_clear_bit(MPTCP_WORK_EOF, &msk->flags))
mptcp_check_for_eof(msk);
@@ -1085,6 +1176,8 @@ static void mptcp_close(struct sock *sk, long timeout)
mptcp_cancel_work(sk);
+ __skb_queue_purge(&sk->sk_receive_queue);
+
sk_common_release(sk);
}
@@ -1755,6 +1848,8 @@ void mptcp_proto_init(void)
panic("Failed to register MPTCP proto.\n");
inet_register_protosw(&mptcp_protosw);
+
+ BUILD_BUG_ON(sizeof(struct mptcp_skb_cb) > sizeof_field(struct sk_buff, cb));
}
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 95b0ade75771..d676b7b6bbd3 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -82,6 +82,7 @@
#define MPTCP_SEND_SPACE BIT(1)
#define MPTCP_WORK_RTX BIT(2)
#define MPTCP_WORK_EOF BIT(3)
+#define MPTCP_WORK_DATA_READY BIT(4)
static inline __be32 mptcp_option(u8 subopt, u8 len, u8 nib, u8 field)
{
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 3/6] mptcp: add rmem queue accounting
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]
If userspace never drains the receive buffers we must stop draining
the subflow socket(s) at some point.
This adds the needed rmem accouting for this.
If the threshold is reached, we stop draining the subflows.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 85d7f73ca804..ac81283d5ec3 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -172,6 +172,10 @@ void mptcp_data_ready(struct sock *sk)
if (test_and_set_bit(MPTCP_WORK_DATA_READY, &msk->flags))
return;
+ /* don't schedule if mptcp sk is (still) over limit */
+ if (atomic_read(&sk->sk_rmem_alloc) > READ_ONCE(sk->sk_rcvbuf))
+ return;
+
sock_hold(sk);
if (!schedule_work(&msk->rtx_work))
sock_put(sk);
@@ -699,7 +703,7 @@ static void __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
struct sock *sk = (struct sock *)msk;
__skb_unlink(skb, &ssk->sk_receive_queue);
- skb_orphan(skb);
+ skb_set_owner_r(skb, sk);
__skb_queue_tail(&sk->sk_receive_queue, skb);
msk->ack_seq += copy_len;
@@ -717,6 +721,7 @@ static bool __mptcp_move_skbs(struct mptcp_sock *msk)
struct sock *ssk;
bool more_data_avail;
struct tcp_sock *tp;
+ int rcvbuf;
ssk = mptcp_subflow_recv_lookup(msk);
if (!ssk)
@@ -726,6 +731,10 @@ static bool __mptcp_move_skbs(struct mptcp_sock *msk)
lock_sock(ssk);
+ rcvbuf = max(ssk->sk_rcvbuf, sk->sk_rcvbuf);
+ if (rcvbuf > sk->sk_rcvbuf)
+ sk->sk_rcvbuf = rcvbuf;
+
tp = tcp_sk(ssk);
do {
u32 map_remaining, offset;
@@ -741,6 +750,11 @@ static bool __mptcp_move_skbs(struct mptcp_sock *msk)
if (!skb)
break;
+ if (!sk_rmem_schedule(sk, skb, skb->truesize)) {
+ done = true;
+ break;
+ }
+
offset = seq - TCP_SKB_CB(skb)->seq;
fin = TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN;
if (fin) {
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 4/6] mptcp: remove mptcp_read_actor
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]
Only used to discard stale data from the subflow, so move
it where needed.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 27 ---------------------------
net/mptcp/protocol.h | 7 -------
net/mptcp/subflow.c | 18 +++++++++++++-----
3 files changed, 13 insertions(+), 39 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index ac81283d5ec3..75ae03931963 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -616,33 +616,6 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
return ret;
}
-int mptcp_read_actor(read_descriptor_t *desc, struct sk_buff *skb,
- unsigned int offset, size_t len)
-{
- struct mptcp_read_arg *arg = desc->arg.data;
- size_t copy_len;
-
- copy_len = min(desc->count, len);
-
- if (likely(arg->msg)) {
- int err;
-
- err = skb_copy_datagram_msg(skb, offset, arg->msg, copy_len);
- if (err) {
- pr_debug("error path");
- desc->error = err;
- return err;
- }
- } else {
- pr_debug("Flushing skb payload");
- }
-
- desc->count -= copy_len;
-
- pr_debug("consumed %zu bytes, %zu left", copy_len, desc->count);
- return copy_len;
-}
-
static void mptcp_wait_data(struct sock *sk, long *timeo)
{
DEFINE_WAIT_FUNC(wait, woken_wake_function);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index d676b7b6bbd3..c6f955f0fd0b 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -304,13 +304,6 @@ void mptcp_proto_init(void);
int mptcp_proto_v6_init(void);
#endif
-struct mptcp_read_arg {
- struct msghdr *msg;
-};
-
-int mptcp_read_actor(read_descriptor_t *desc, struct sk_buff *skb,
- unsigned int offset, size_t len);
-
void mptcp_get_options(const struct sk_buff *skb,
struct tcp_options_received *opt_rx);
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index fbff5dc39575..da984f2af7ac 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -577,6 +577,18 @@ static enum mapping_status get_mapping_status(struct sock *ssk)
return MAPPING_OK;
}
+static int subflow_read_actor(read_descriptor_t *desc,
+ struct sk_buff *skb,
+ unsigned int offset, size_t len)
+{
+ size_t copy_len = min(desc->count, len);
+
+ desc->count -= copy_len;
+
+ pr_debug("flushed %zu bytes, %zu left", copy_len, desc->count);
+ return copy_len;
+}
+
static bool subflow_check_data_avail(struct sock *ssk)
{
struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
@@ -651,16 +663,12 @@ static bool subflow_check_data_avail(struct sock *ssk)
pr_debug("discarding %zu bytes, current map len=%d", delta,
map_remaining);
if (delta) {
- struct mptcp_read_arg arg = {
- .msg = NULL,
- };
read_descriptor_t desc = {
.count = delta,
- .arg.data = &arg,
};
int ret;
- ret = tcp_read_sock(ssk, &desc, mptcp_read_actor);
+ ret = tcp_read_sock(ssk, &desc, subflow_read_actor);
if (ret < 0) {
ssk->sk_err = -ret;
goto fatal;
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 5/6] mptcp: protocol: re-check dsn before reading from subflow
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
mptcp_subflow_data_available() is commonly called via
ssk->sk_data_ready(), in this case the mptcp socket lock
cannot be acquired.
Therefore, while we can safely discard subflow data that
was already received up to msk->ack_seq, we cannot be sure
that 'subflow->data_avail' will still be valid at the time
userspace wants to read the data -- a previous read on a
different subflow might have carried this data already.
In that (unlikely) event, msk->ack_seq will have been updated
and will be ahead of the subflow dsn.
We can check for this condition and skip/resync to the expected
sequence number.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 75ae03931963..02aba8b31f1f 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -205,8 +205,24 @@ static struct sock *mptcp_subflow_recv_lookup(const struct mptcp_sock *msk)
sock_owned_by_me(sk);
mptcp_for_each_subflow(msk, subflow) {
- if (subflow->data_avail)
- return mptcp_subflow_tcp_sock(subflow);
+ if (subflow->data_avail) {
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+ u64 dsn = mptcp_subflow_get_mapped_dsn(subflow);
+
+ /* revalidate data sequence number.
+ *
+ * mptcp_subflow_data_available() is usually called
+ * without msk lock. Its unlikely (but possible)
+ * that msk->ack_seq has been advanced since the last
+ * call found in-sequence data.
+ */
+ if (likely(dsn == msk->ack_seq))
+ return ssk;
+
+ subflow->data_avail = 0;
+ if (mptcp_subflow_data_available(ssk))
+ return ssk;
+ }
}
return NULL;
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 6/6] mptcp: send acks when moving skbs to mptcp receive queue
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]
This isn't strictly required, however, without this we will
punish flows that don't do bluk transmits as they will lag
behind in their window updates sent to peer.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
include/net/tcp.h | 1 +
net/ipv4/tcp.c | 2 +-
net/mptcp/protocol.c | 3 +++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index a5ea27df3c2b..454ecab0df8b 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -650,6 +650,7 @@ static inline int tcp_bound_to_half_wnd(struct tcp_sock *tp, int pktsize)
/* tcp.c */
void tcp_get_info(struct sock *, struct tcp_info *);
+void tcp_cleanup_rbuf(struct sock *sk, int copied);
/* Read 'sendfile()'-style from a TCP socket */
int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1b685485a5b5..62362885a518 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1517,7 +1517,7 @@ static int tcp_peek_sndq(struct sock *sk, struct msghdr *msg, int len)
* calculation of whether or not we must ACK for the sake of
* a window update.
*/
-static void tcp_cleanup_rbuf(struct sock *sk, int copied)
+void tcp_cleanup_rbuf(struct sock *sk, int copied)
{
struct tcp_sock *tp = tcp_sk(sk);
bool time_to_ack = false;
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 02aba8b31f1f..93963bf3f9fe 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -773,6 +773,9 @@ static bool __mptcp_move_skbs(struct mptcp_sock *msk)
more_data_avail = mptcp_subflow_data_available(ssk);
} while (more_data_avail);
+ if (moved > 0)
+ tcp_cleanup_rbuf(ssk, moved);
+
release_sock(ssk);
} while (!done);
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v1] MAINTAINERS: Sort entries in database for TI VPE/CAL
From: Benoit Parrot @ 2020-02-20 14:38 UTC (permalink / raw)
To: Andy Shevchenko, Mauro Carvalho Chehab
Cc: linux-media, linux-kernel, Linus Torvalds
In-Reply-To: <20200128145828.74161-1-andriy.shevchenko@linux.intel.com>
Mauro,
Can you pick up this patch?
There is already been at least 3 other similar patches posted in the last
month.
Thanks,
Benoit
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote on Tue [2020-Jan-28 16:58:28 +0200]:
> Run parse-maintainers.pl and choose TI VPE/CAL record. Fix it accordingly.
>
> Note, this is urgent fix, without which parse-maintainers.pl throws
> an exception:
>
> Odd non-pattern line ' Documentation/devicetree/bindings/media/ti,cal.yaml
> ' for 'TI VPE/CAL DRIVERS' at scripts/parse-maintainers.pl line 147, <$file> line 16770.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> MAINTAINERS | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9fbe2a19b8a3..f04b1c6508fe 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16761,12 +16761,12 @@ F: sound/soc/codecs/twl4030*
> TI VPE/CAL DRIVERS
> M: Benoit Parrot <bparrot@ti.com>
> L: linux-media@vger.kernel.org
> +S: Maintained
> W: http://linuxtv.org/
> Q: http://patchwork.linuxtv.org/project/linux-media/list/
> -S: Maintained
> -F: drivers/media/platform/ti-vpe/
> +F: Documentation/devicetree/bindings/media/ti,cal.yaml
> F: Documentation/devicetree/bindings/media/ti,vpe.yaml
> - Documentation/devicetree/bindings/media/ti,cal.yaml
> +F: drivers/media/platform/ti-vpe/
>
> TI WILINK WIRELESS DRIVERS
> L: linux-wireless@vger.kernel.org
> --
> 2.24.1
>
^ permalink raw reply
* Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature
From: Eric Blake @ 2020-02-20 14:33 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <0b884ddcd0ac3a3c0b8cdd9d09c74566ac107c9a.1577014346.git.berto@igalia.com>
On 12/22/19 5:36 AM, Alberto Garcia wrote:
> Subcluster allocation in qcow2 is implemented by extending the
> existing L2 table entries and adding additional information to
> indicate the allocation status of each subcluster.
>
> This patch documents the changes to the qcow2 format and how they
> affect the calculation of the L2 cache size.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> @@ -437,7 +445,7 @@ cannot be relaxed without an incompatible layout change).
> Given an offset into the virtual disk, the offset into the image file can be
> obtained as follows:
>
> - l2_entries = (cluster_size / sizeof(uint64_t))
> + l2_entries = (cluster_size / sizeof(uint64_t)) [*]
>
> l2_index = (offset / cluster_size) % l2_entries
> l1_index = (offset / cluster_size) / l2_entries
> @@ -447,6 +455,8 @@ obtained as follows:
>
> return cluster_offset + (offset % cluster_size)
>
> + [*] this changes if Extended L2 Entries are enabled, see next section
> +The size of an extended L2 entry is 128 bits so the number of entries per table
> +is calculated using this formula:
> +
> + l2_entries = (cluster_size / (2 * sizeof(uint64_t)))
Is it worth unifying these statements by writing:
l2_entries = (cluster_size / ((1 + extended_l2) * sizeof(uint64_t)))
or is that too confusing?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* RE: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU
From: Chris Paterson @ 2020-02-20 14:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Russell King - ARM Linux admin,
Linus Torvalds, Michal Hocko, Rik van Riel, Catalin Marinas,
kernel-team@fb.com, Dave Chinner, Linux Kernel Mailing List,
Linux-MM, Yafang Shao, Al Viro, Johannes Weiner, linux-fsdevel,
Andrew Morton, Roman Gushchin, Linux ARM, Kishon Vijay Abraham I,
Santosh Shilimkar, cip-dev@lists.cip-project.org
In-Reply-To: <CAK8P3a3Za8dthPE7czQs+rK+xUq+ZZC4Sbj8QF5YjXvtfzop4Q@mail.gmail.com>
Hello,
> From: Arnd Bergmann <arnd@arndb.de>
> Sent: 16 February 2020 20:38
>
> On Sun, Feb 16, 2020 at 8:54 PM Chris Paterson
> <Chris.Paterson2@renesas.com> wrote:
> >
> > Hello Arnd, Geert,
> >
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Sent: 16 February 2020 09:45
> > > To: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Hi Arnd,
> > >
> > > On Sat, Feb 15, 2020 at 5:59 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Sat, Feb 15, 2020 at 12:25 PM Geert Uytterhoeven
> > > > <geert@linux-m68k.org> wrote:
> > > > > On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann <arnd@arndb.de>
> > > wrote:
> > > > > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin
> > > > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split
> (even
> > > > > for 1 GiB or 2 GiB configurations) in two parts, one below and one
> above
> > > > > the 32-bit physical limit.
> >
> > Yep. One example is r8a7743-iwg20m.dtsi.
>
> This one has 2x512MB, with half above the 4GiB limit. This means it needs
> LPAE to address high physical addresses (which is fine), but it does not need
> highmem if one uses an appropriate CONFIG_VMSPLIT_* option.
>
> > > > Good to know. I think there are several other chips that have dual-
> channel
> > > > DDR3 and thus /can/ support this configuration, but this rarely happens.
> > > > Are you aware of commercial products that use a 4GB configuration,
> aside
> > > from
> > > > the reference board?
> >
> > iWave Systems make a range of SOM modules using the RZ/G1 SoCs.
> > I believe there are options for some of these to use 4 GB, although 1 or 2
> GB is
> > used in the boards we've upstreamed support for.
> >
> > There are also other SOM vendors (e.g. Emtrion) and end users of RZ/G1,
> > but I'm not sure of the details.
>
> Both iWave and Emtrion only seem to list boards with 2GB or less on their
> websites today (with up to 15 year availability). My guess is that they had
> the same problem as everyone else in finding the right memory chips in
> the required quantities and/or long-term availability. iWave lists "By default
> 1GB DDR3 and 4GB eMMC only supported. Contact iWave for memory
> expansion support." on some boards, but that doesn't mean they ever
> shipped a 4GB configuration.
I probably should have been clearer before - I actually have a couple of iWave RZ/G1M SOM modules with 4GB DDR on them.
However I've never booted them nor do I know what the memory mapping is.
Kind regards, Chris
>
> Arnd
^ permalink raw reply
* RE: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU
From: Chris Paterson @ 2020-02-20 14:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux ARM, Michal Hocko, Rik van Riel, Catalin Marinas,
Santosh Shilimkar, Dave Chinner, Russell King - ARM Linux admin,
Linux Kernel Mailing List, Linux-MM, Yafang Shao,
Geert Uytterhoeven, Al Viro, cip-dev@lists.cip-project.org,
Johannes Weiner, linux-fsdevel, kernel-team@fb.com,
Kishon Vijay Abraham I, Linus Torvalds, Andrew Morton,
Roman Gushchin
In-Reply-To: <CAK8P3a3Za8dthPE7czQs+rK+xUq+ZZC4Sbj8QF5YjXvtfzop4Q@mail.gmail.com>
Hello,
> From: Arnd Bergmann <arnd@arndb.de>
> Sent: 16 February 2020 20:38
>
> On Sun, Feb 16, 2020 at 8:54 PM Chris Paterson
> <Chris.Paterson2@renesas.com> wrote:
> >
> > Hello Arnd, Geert,
> >
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Sent: 16 February 2020 09:45
> > > To: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Hi Arnd,
> > >
> > > On Sat, Feb 15, 2020 at 5:59 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Sat, Feb 15, 2020 at 12:25 PM Geert Uytterhoeven
> > > > <geert@linux-m68k.org> wrote:
> > > > > On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann <arnd@arndb.de>
> > > wrote:
> > > > > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin
> > > > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split
> (even
> > > > > for 1 GiB or 2 GiB configurations) in two parts, one below and one
> above
> > > > > the 32-bit physical limit.
> >
> > Yep. One example is r8a7743-iwg20m.dtsi.
>
> This one has 2x512MB, with half above the 4GiB limit. This means it needs
> LPAE to address high physical addresses (which is fine), but it does not need
> highmem if one uses an appropriate CONFIG_VMSPLIT_* option.
>
> > > > Good to know. I think there are several other chips that have dual-
> channel
> > > > DDR3 and thus /can/ support this configuration, but this rarely happens.
> > > > Are you aware of commercial products that use a 4GB configuration,
> aside
> > > from
> > > > the reference board?
> >
> > iWave Systems make a range of SOM modules using the RZ/G1 SoCs.
> > I believe there are options for some of these to use 4 GB, although 1 or 2
> GB is
> > used in the boards we've upstreamed support for.
> >
> > There are also other SOM vendors (e.g. Emtrion) and end users of RZ/G1,
> > but I'm not sure of the details.
>
> Both iWave and Emtrion only seem to list boards with 2GB or less on their
> websites today (with up to 15 year availability). My guess is that they had
> the same problem as everyone else in finding the right memory chips in
> the required quantities and/or long-term availability. iWave lists "By default
> 1GB DDR3 and 4GB eMMC only supported. Contact iWave for memory
> expansion support." on some boards, but that doesn't mean they ever
> shipped a 4GB configuration.
I probably should have been clearer before - I actually have a couple of iWave RZ/G1M SOM modules with 4GB DDR on them.
However I've never booted them nor do I know what the memory mapping is.
Kind regards, Chris
>
> Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 4/4] ci: reorganise Travis jobs
From: Aaron Conole @ 2020-02-20 14:35 UTC (permalink / raw)
To: David Marchand; +Cc: Thomas Monjalon, dev, Michael Santana, Bruce Richardson
In-Reply-To: <CAJFAV8wWC9Sxeebt+nKPz81h8pHd+fK2uQi16HCfjsA8LCzMtA@mail.gmail.com>
David Marchand <david.marchand@redhat.com> writes:
> On Thu, Feb 20, 2020 at 11:42 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>>
>> 19/02/2020 22:39, Aaron Conole:
>> > David Marchand <david.marchand@redhat.com> writes:
>> >
>> > > Let's prune the jobs list to limit the amount of time spent by the robot
>> > > in Travis.
>> > >
>> > > Since meson enables automatically the relevant components, there is not
>> > > much gain in testing with extra_packages vs required_packages only.
>> > >
>> > > For a given arch/compiler/env combination, compilation is first tested
>> > > in all jobs that run tests or build the docs or run the ABI checks.
>> > > In the same context, for jobs that accumulates running tests, building
>> > > the docs etc..., those steps are independent and can be split to save
>> > > some cpu on Travis.
>> > >
>> > > With this, we go down from 21 to 15 jobs.
>> > >
>> > > Note: this patch requires a flush of the existing caches in Travis.
>> > >
>> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
>> > > ---
>> >
>> > In general, I think the idea with required vs. extra was to have a build
>> > that did the minimum required, and one that did all the packages (to
>> > allow a minimum vs. full DPDK).
>> >
>> > At least, that's from
>> > http://mails.dpdk.org/archives/dev/2019-January/124007.html
>>
>> I think the benefit of a minimum build is to have a quick report,
>> and easy to setup.
>
> Yes, Travis serves as a first gate when submitting patches.
> But since Travis is best effort/free, we can't have a full coverage.
>
>
>> > Not sure if that's still something anyone cares about.
>>
>> Given that Travis knows how to satisfy the dependencies,
>> and that we must wait for all jobs to finish,
>> I don't see any benefit of a minimal setup.
>
> This minimal setup also tests that dpdk dependencies are correct.
> If a change makes something rely on libX and libX is in the packages
> always installed in Travis, the missing dependency would not get
> caught.
>
> But here, this adds too many jobs.
>
> UNH, Intel and other CIs should step in and fill this kind of gap.
Okay, makes sense to me. Are one of these CI providers offering to
cover this?
Also,
Acked-by: Aaron Conole <aconole@redhat.com>
>
> --
> David Marchand
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 3/4] ci: use an explicit list of Travis jobs
From: Aaron Conole @ 2020-02-20 14:35 UTC (permalink / raw)
To: David Marchand; +Cc: thomas, dev, Michael Santana
In-Reply-To: <20200219194131.29417-4-david.marchand@redhat.com>
David Marchand <david.marchand@redhat.com> writes:
> Maintaining the .travis.yml requires some knowledge of how Travis
> computes the jobs list (combination of os: arch: compiler: etc...).
> Let's switch to an explicit list to find all jobs at a glance.
>
> To enhance readability, jobs have been sorted per arch/compiler with
> comments to isolate blocks.
>
> Setting required_packages for aarch64 native jobs is unnecessary,
> the global addons: values are the same.
>
> This commit does not change the jobs list (21 jobs in total).
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
Acked-by: Aaron Conole <aconole@redhat.com>
^ permalink raw reply
* [Cluster-devel] [PATCH v7 04/24] mm: Move readahead nr_pages check into read_pages
From: Zi Yan @ 2020-02-20 14:36 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <20200219210103.32400-5-willy@infradead.org>
On 19 Feb 2020, at 16:00, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Simplify the callers by moving the check for nr_pages and the BUG_ON
> into read_pages().
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> mm/readahead.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 61b15b6b9e72..9fcd4e32b62d 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -119,6 +119,9 @@ static void read_pages(struct address_space *mapping, struct file *filp,
> struct blk_plug plug;
> unsigned page_idx;
>
> + if (!nr_pages)
> + return;
> +
> blk_start_plug(&plug);
>
> if (mapping->a_ops->readpages) {
> @@ -138,6 +141,8 @@ static void read_pages(struct address_space *mapping, struct file *filp,
>
> out:
> blk_finish_plug(&plug);
> +
> + BUG_ON(!list_empty(pages));
> }
>
> /*
> @@ -180,8 +185,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * contiguous pages before continuing with the next
> * batch.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages,
> + read_pages(mapping, filp, &page_pool, nr_pages,
> gfp_mask);
> nr_pages = 0;
> continue;
> @@ -202,9 +206,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * uptodate then the caller will launch readpage again, and
> * will then handle the error.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> - BUG_ON(!list_empty(&page_pool));
> + read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> }
>
> /*
> --
> 2.25.0
Looks good to me. Thanks.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan Zi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 854 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20200220/419c5d42/attachment.sig>
^ permalink raw reply
* [Ocfs2-devel] [PATCH v7 04/24] mm: Move readahead nr_pages check into read_pages
From: Zi Yan @ 2020-02-20 14:36 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <20200219210103.32400-5-willy@infradead.org>
On 19 Feb 2020, at 16:00, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Simplify the callers by moving the check for nr_pages and the BUG_ON
> into read_pages().
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> mm/readahead.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 61b15b6b9e72..9fcd4e32b62d 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -119,6 +119,9 @@ static void read_pages(struct address_space *mapping, struct file *filp,
> struct blk_plug plug;
> unsigned page_idx;
>
> + if (!nr_pages)
> + return;
> +
> blk_start_plug(&plug);
>
> if (mapping->a_ops->readpages) {
> @@ -138,6 +141,8 @@ static void read_pages(struct address_space *mapping, struct file *filp,
>
> out:
> blk_finish_plug(&plug);
> +
> + BUG_ON(!list_empty(pages));
> }
>
> /*
> @@ -180,8 +185,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * contiguous pages before continuing with the next
> * batch.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages,
> + read_pages(mapping, filp, &page_pool, nr_pages,
> gfp_mask);
> nr_pages = 0;
> continue;
> @@ -202,9 +206,7 @@ void __do_page_cache_readahead(struct address_space *mapping,
> * uptodate then the caller will launch readpage again, and
> * will then handle the error.
> */
> - if (nr_pages)
> - read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> - BUG_ON(!list_empty(&page_pool));
> + read_pages(mapping, filp, &page_pool, nr_pages, gfp_mask);
> }
>
> /*
> --
> 2.25.0
Looks good to me. Thanks.
Reviewed-by: Zi Yan <ziy@nvidia.com>
--
Best Regards,
Yan Zi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 854 bytes
Desc: OpenPGP digital signature
Url : http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20200220/419c5d42/attachment-0001.bin
^ permalink raw reply
* Re: [PATCH v3 4/5] sched/pelt: Add a new runnable average signal
From: Vincent Guittot @ 2020-02-20 14:36 UTC (permalink / raw)
To: Valentin Schneider
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel, Phil Auld,
Parth Shah, Hillf Danton
In-Reply-To: <9fe822fc-c311-2b97-ae14-b9269dd99f1e@arm.com>
On Wed, 19 Feb 2020 at 21:10, Valentin Schneider
<valentin.schneider@arm.com> wrote:
>
> On 19/02/2020 12:55, Vincent Guittot wrote:
> > @@ -740,8 +740,10 @@ void init_entity_runnable_average(struct sched_entity *se)
> > * Group entities are initialized with zero load to reflect the fact that
> > * nothing has been attached to the task group yet.
> > */
> > - if (entity_is_task(se))
> > + if (entity_is_task(se)) {
> > + sa->runnable_avg = SCHED_CAPACITY_SCALE;
>
> So this is a comment that's more related to patch 5, but the relevant bit is
> here. I'm thinking this initialization might be too aggressive wrt load
> balance. This will also give different results between symmetric vs
> asymmetric topologies - a single fork() will make a LITTLE CPU group (at the
> base domain level) overloaded straight away. That won't happen for bigs or on
> symmetric topologies because
>
> // group_is_overloaded()
> sgs->group_capacity * imbalance_pct) < (sgs->group_runnable * 100)
>
> will be false - it would take more than one task for that to happen (due to
> the imbalance_pct).
>
> So maybe what we want here instead is to mimic what he have for utilization,
> i.e. initialize to half the spare capacity of the local CPU. IOW,
> conceptually something like this:
>
> ---
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 99249a2484b4..762717092235 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -740,10 +740,8 @@ void init_entity_runnable_average(struct sched_entity *se)
> * Group entities are initialized with zero load to reflect the fact that
> * nothing has been attached to the task group yet.
> */
> - if (entity_is_task(se)) {
> - sa->runnable_avg = SCHED_CAPACITY_SCALE;
> + if (entity_is_task(se))
> sa->load_avg = scale_load_down(se->load.weight);
> - }
>
> /* when this task enqueue'ed, it will contribute to its cfs_rq's load_avg */
> }
> @@ -796,6 +794,8 @@ void post_init_entity_util_avg(struct task_struct *p)
> }
> }
>
> + sa->runnable_avg = sa->util_avg;
> +
> if (p->sched_class != &fair_sched_class) {
> /*
> * For !fair tasks do:
> ---
>
> The current approach has the merit of giving some sort of hint to the LB
> that there is a bunch of new tasks that it could spread out, but I fear it
> is too aggressive.
I agree that setting by default to SCHED_CAPACITY_SCALE is too much
for little core.
The problem for little core can be fixed by using the cpu capacity instead
@@ -796,6 +794,8 @@ void post_init_entity_util_avg(struct task_struct *p)
}
}
+ sa->runnable_avg = cpu_scale;
+
if (p->sched_class != &fair_sched_class) {
/*
* For !fair tasks do:
>
> > sa->load_avg = scale_load_down(se->load.weight);
> > + }
> >
> > /* when this task enqueue'ed, it will contribute to its cfs_rq's load_avg */
> > }
^ permalink raw reply
* Re: [PATCH v3 03/10] ASoC: tegra: add Tegra210 based DMIC driver
From: Jon Hunter @ 2020-02-20 14:36 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-4-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital MIC (DMIC) Controller is used to interface with Pulse Density
> Modulation (PDM) input devices. The DMIC controller implements a converter
> to convert PDM signals to Pulse Code Modulation (PCM) signals. From signal
> flow perspective, the DMIC can be viewed as a PDM receiver.
>
> This patch registers DMIC component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DMIC interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DMIC devices can be enabled in the DT via
> "nvidia,tegra210-dmic" compatible string. This driver can be used for
> Tegra186 and Tegra194 chips as well.
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Thanks!
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.